Java Database Programming with JDBC Java Database Programming with JDBC
by Pratik Patel
Coriolis, The Coriolis Group
ISBN: 1576100561   Pub Date: 10/01/96
  

Previous Table of Contents Next


The Applet Security Manager

Every Web browser’s Java interpreter includes a security manager to determine what an applet can and can’t do. For instance, the security mangager does not allow applets downloaded from remote Web pages to access the local disk; it restricts network connections attempted by the applet to only the machine from which the applet came from; and it restricts applets from gaining control of local system devices. These restrictions are in place to protect users from rogue applets (or should I say rogue applet programmers) attempting to break into your computer. The user does not need to worry about the applet formatting the hard disk or reading password files. Of course, I’m simplifying the applet security scheme, but I want to point out the care that is taken to protect the user, and the restrictions that developers are faced with when programming applets. So how does this relate to the JDBC? The immediate concern for you as the developer is that your JDBC applet can only connect to the same machine that served the applet initially (i.e. your Web server). This means that you must run a Web server on the same machine as your database server. However, if you choose the application server route that we will discuss in Chapter 11, you must run the application server alongside the Web server, but then you are free to run the database server on another machine. If the user installs the applet locally and runs it, these security restrictions do not apply. But unfortunately, that defeats the purpose behind an applet: a program that comes over the network and begins running locally without installation.

I’m A Certified Applet

To account for these tight security restrictions, the Java Commerce API addresses easing security if the applet comes from a “trusted” source. This means that if the Web browser recognizes as genuine the certification of the Web page, applets on the page may also be considered “certified.” To obtain such a status, you must apply for certification from the proper authority. When you receive certification, simply attach it to applets that are served from your Web site. The Commerce and Security APIs allow for the fetching of trusted applets, so if the user uses a Java interpreter that incorporates the Java Commerce API and Security API, you (the developer) can serve applets that can connect to an application server or database server running on a different machine than the Web server. In fact, you can even attach to different database servers simultaneously if necessary. In addition, this approach may allow the applet to save the contents of a database session on the user’s disk, or read data from the user’s disk to load previous session data.

The exact security restrictions of trusted applets are not set in stone, and they may differ depending on the Web browser the applet is run on. Also, the Java Commerce and Security specifications and related APIs have not been finalized as of the writing of this book, so much may change from the preliminary details of the security scheme by the time the APIs are released and implemented.

Summary

Security in data transactions is a top priority in the Internet community. In this chapter, we’ve discussed possible security holes and techniques to sew them up. We also took a look at Javasoft’s approach to easing security restrictions for applets that come from a certified trusted source.

In the next chapter, we jump back into the meat of the JDBC when we explore writing JDBC drivers. We’ll explore the heart of the JDBC’s implementation details, and we’ll also develop a real JDBC driver that can serve as the basis for drivers you write in the future.


Previous Table of Contents Next